There are no prior examples to be able to assess the truthfulness of this statement. Significant changes could be required for any increased level.

Fair point. It's true that L3 already has a very similar statement, and we still wanted to be explicit about the fact that this L4 would require additional significant changes on top of L3. We can be more precise in what we mean here: for example, one of the significant requirements is hardware with very particular features (e.g., TPM or TEE support). Would that be more helpful here?

I'm sympathetic to view that we can just repeat the language from L3 (unless we also want to rewrite the L3 'intended for' section). Maybe with the caveat "significant changes to existing L3 builds platforms"?

I think the requirements below do a fine job of getting into the details.

What would this look like? I would expect that the build system would create a build environment attestation on the artifact. I feel like it is a lot to ask for a producer to verify it and publish the VSA. Or does this not have to be a human/manual process?

The main goal of the proposed requirements is to make tampering prior to a build detectable. That is, at any point from when a build image is itself created/released to the point where a VM is deployed and waiting for a new build job to come in. This means the build platform will actually generate its attestations before and independently of the artifact. We have a figure showing this sequence which I think would be helpful in clarifying things.

I'll note that the point of using hardware-based integrity measurements and attestation for this is to reduce the amound of manual self-attestation and verification that needs to happen on the part of the build platform and producer. I'll also note that this requirement is a SHOULD, so producer's aren't strictly required to check these attestations.

The VMs must be built on a SLSA Build L3+ platform as well? What does this mean in practice?

Yes, we're using the creation process of the VM image to bootstrap a first degree of trust in the build environment. Today we're already placing trust in GHA to configure an L3 platform, so say GHA VM images were themselves built on GHA, this requirement would give us assurances that the VM images were built with the same L3 integrity. It's a bit recursive, much like building gcc with gcc is, but the guarantees provided by the rest of the requirements become significantly weakened if we didn't have integrity for the build environment's build process. This is because the Provenance of the VM image gives us the good known value that can be later check against when the VM is deployed.

I should also add that the conditions for meeting requirement are meant to be binary. That is, L4 is achieved iff the VM image is built on a SLSA Build L3+ platform. We believe this is necessary to get around the issue of resolving what the transitive SLSA level would be.

This text also presupposes that all builders run in VMs. Are we categorically rejecting remote attestations from physical TPMs on non-virtual machines?

@deeglaze Can you please clarify, when you say non-VM, do you mean that a build could be running inside a container (backed by a physical TPM), or a bare metal environment, or either? There are a few reasons why we're preferring VM-based environments, but I'd like to track the discussion around other settings.

I mean a task that is launched by a trusted orchestration daemon that establishes some resource limitations and filesystem access restrictions as Linux allows, but not necessarily following an OCI container description. At Google we have build servers that only run builds but still run on Borg. All the node software is accounted for with Titan TPMs. There’s no strong reason for us to require builds to run in VMs since we have everything measured and can account for the machine access by the identity and access management system and (measured) software-enforced ACLs. The build environment is managed by this production identity system before getting to the build job that then measures the inputs for slsa L3 but without incorporating the measurement into pcrs.

The hardware attestation of prodID and software attestation by borg Id (BCID) protect our build environment integrity in an auditable manner, but without incorporating the entirety of our production ecosystem in the build attestation. The new slsa level should allow for ecosystem measurements to be held back if the operational security and physical security of the servers can ve attested to implicitly with the slsa signing key release mechanism.

Now if you’re saying that the build ecosystem integrity is only a means to an end of requiring the build to be run within confidential computing technologies, I’d say that is not the most important goal to reach. If you want the build ecosystem to satisfy holistic properties like “no humans may access the environment” then you have to talk about more security commitments of the software, not just its measurement.

Thanks for the detailed explanation!

The provenance for what must be distributed the build image? This is already a requirement for build L1-3: https://slsa.dev/spec/v1.0/requirements#distribute-provenance . Is the intention for this provenance to be verified somehow?

How would this distribution happen? Are we trying to add recursive SLSA into this requirement? Is that too much to do?

We aren't trying to add recursive SLSA in this requirement. The intent here is to clarify that while SLSA Provenance is required for the build image creation, SLSA Provenance for pre-installed software (e.g., the Linux kernel, packages etc) is not expected of the build platform.

These changes are proposed to be part of the build track but we are now adding additional required attestations into the mix (this attestation + the producer's VSA mentioned earlier). I know that we do not have a 1:1 relationship between attestations and tracks, but this seems to be muddling the simplicity of the build track. Would this proposal be better as its own track?

You raise a valid point about preserving the simplicity build track, and the types of attestations being a part of that. The intent here is to actually encapsulate the hardware-based attestations inside an in-toto attestation, to at least ensure we remain within the SLSA attestation model. So at Build L4 there would be two types of in-toto attestations that would be generated: SLSA Provenance and SCAI encapsulating the hardware-based attestations. We think this approach helps us keep the attestation types limited to a select few. I'll add a TODO item to include examples of these attestations to illustrate what we would expect, and that'll hopefully clarify some of these questions.

On the question of converting this workstream into its own track, our original proposal went down that path. But we got some very convincing feedback from some in the community that that would actually introduce more complexity than is necessary in SLSA overall when the Build Track already pertains to properties of the build platform.

Does this need to be included in the attestation?

Can you clarify the presence of the key? I assume that you are not trying to say that the encryption key should be present in the image used to run the VM/container as then it would be reused for multiple running instances of the build.

What are the criteria for verification here? Is it just the identity or is there more verification needed than that? Are we supposed to verify that it has met some SLSA level?

The main aspect to verify here is the identity/hash of the build image against what's recorded in the Provenance. Checking the SLSA level of the Provenance here gives extra assurances about the trustworthiness of the hash. In practice, this check would follow the standard verification flow. I'll revise this requirement to make the intent clearer.

This verification feels different than the previously mentioned one. Is it?

I recommend removing these requirements. In my mind, the requirement should be relatively simple: there is a hardware-backed attestation (SEV-SNP, TDX, or equivalent) attesting to:

• the entire initial state of the build environment (bootloader, kernel, filesystem, etc)
• all of the inputs to the build

The properties of those inputs, such as the VM, seem outside the scope. There are many inputs to the build, and I would assume that we should verify each of those separately as part of some "transitive SLSA" verification.

Agreed, I realized looking at this again more recently that this list really enumerates low-level mechanisms for achieving the high-level properties, rather than stating those high-level properties. My thinking is that a lot of the content currently here would ultimately move to the requirements.md description.

The properties of those inputs, such as the VM, seem outside the scope. There are many inputs to the build, and I would assume that we should verify each of those separately as part of some "transitive SLSA" verification.

I generally agree with the notion that inputs/dependencies to the build should be verified separately. At the same time, the properties of the VM specifically are needed to check the initial state of the build environment. That is, in order for the platform or a strict producer to verify the initial state of the build environment it needs to have good known reference values to check against. The SLSA L3 Provenance for the build image's build provides this good known value, with strong integrity assurances, that can then be bootstrapped to gain trust in the integrity of the initial state of the build environment.

there is a hardware-backed attestation (SEV-SNP, TDX, or equivalent) attesting to ... all of the inputs to the build

@MarkLodato Thinking about this some more as I reformulate the requirements. What do you mean by "inputs to the build"? Is this about the completeness of external parameters in the Provenance? If so, one way to accomplish this requirement is to sign the Provenance itself with the hardware root of trust. Is this what you have in mind?

An alternate framing would be that it removes almost all of the build platform from the root of trust. All that's left is the hardware vendor and physical access.

At a high level, this is true, and we should probably keep this section more concise than it currently is. We did want to capture some of the nuance of doing this practice, though. For example, you actually need to still place a fair amount of trust in the cloud provider that's hosting the VMs running the builds to not tamper with components like the host OS or the vTPM implementation being used to check the integrity of the build environment. The other part we wanted to emphasize is the machine-checkable aspect of relying on the attestable hardware, compared to the expectations for verification at L3. Maybe this nuance doesn't need to be covered in such detail here?

I see the importance of capturing the nuance. I think what Mark might be getting at is that the benefits as currently enumerated are a bit abstract.

E.g. "Greatly reduces trust in a hosted build platform by increasing observability into the level of integrity of the build environment."

Could this instead be something like "Greatly reduces the TCB of a hosted build platform by preventing tampering with the build execution environment, leaving only the OS and vTPM in scope" or something like that?

We may want to clarify "hardware" here. A vTPM is not "hardware" but is a software implementation of TPM that appears to the VM as if it were hardware.

There's actually a note at the end of the requirements clarifying that virtual hardware also works. Do you think that's enough, or is it worth clarifying up front?

In a TEE featuring a vTPM there should still be a hardware root of trust. The vTPM would be linked to signed HW evidence, for by example by mixing a hash of the vTPMs AKpub into the report-data field of a TEE's attestation report.

So, the original statement sounds fine to me. I assume a HW RoT is key and not something that can be supplanted by sw.

I do wonder if there's a useful middle ground where vTPMs that aren't hardware backed can still provide meaningful value. If this level requires full hardware backed support would that be too big a step?

I think another potential middle ground is a HSM where authentication requires certain authentication requirements (whether secure/measured boot, validating PCRs, some validated token, etc.)?

In this case I'd explicitly state here that "software vTPMs" are valid too. sth like:

All attestations MUST be authenticated a root of trust. A valid of root of trust might be anchored in a dedicated HW module or might be formed via a chain of cryptographic signatures.

The latter would be referring to vTPMs that are provisioned by a cloud service provider on tenant VMs and for which you'd get a CSP-provided cert-chain to verify.

I think I would separate VM and container images. VM image should always be attested while the container image should be attested if containers are being used. Something like:

(i.e., VM image, kernel, filesystem, and container image if containers are used)

To clarify, you specifically mean the case where a container is used within a VM, right? My intent here was more to cover the scenario in which container-only build images are used. Whether or not containers are sufficient to achieve L3, I think is a related but separate question.

I know that "hardware-rooted" has been used a fair bit when describing confidential computing environments, but it is misleading and not representative of the desired property.

I'm not sure binding the specification to TCG as the only trustworthy industry standard body is required.

Are these deployment assertions meant to be checkable from each of the build environment's output build attestations, or are these operational attestations for claiming SLSA L4? I can't really prove to folks that I did a check before starting the builder VM unless I'm already in a builder VM, which doesn't seem like the right scope.

OR is this saying that the build image's SLSA provenance MUST be verified as a component of the DRTM's remote attestation for the built artifacts? Is delegating that verification to a VSA already understood as an acceptable verification?

Is this item meant to address the Google doc comment of attestation verification policy-based key provisioning for SLSA L4 build attestation signing keys? If so, I think this could be clearer. I'm not familiar enough with SLSA mechanics to know whether SLSA level is expected to be assigned by a specific cryptographic key usage.

What does this mean? I imagine that the SLSA L4 attestation signing key would be deleted from memory after use from a previous build job, so yes you'd need to re-establish the attestation with the key management service, but only AFTER the build request has completed. You don't want the key material in memory while an untrusted build process is taking place, even if it is isolated.

Who does the build environment attestation verification? It seems like the build job is accepting itself from this wording. The build requester would not necessarily be the one with an appropriate attestation verification policy to apply before even initiating a build request, but maybe that's what you meant? Is a build request supposed to happen over an attested channel?

I don't think request-time attestation is what's desirable. Although it could be an enhancement for tenant confidentiality, i.e., "I don't want to release my code to a builder I haven't vetted."
For build integrity, we want response-time attestation in order for both input and output resource descriptors to be cryptographically bound to the attestation. This prevents replay attacks given that the attestations are meant to be verified offline (i.e., not during the build process where the environment could respond to a cryptographic challenge for freshness).

When you say "prior to", do you mean that there is a separator event between boot to the build executor and the executor running any build request? That's my expectation, but this also seems like there could be a temporal prior, where an attestation verification service must do this verification before providing a ticket (for example) to permit the build request to proceed. I don't think the latter is desirable. See my later comment about response-time attestations.

This definition of build image as including parts from a tenant seems contrary to prior uses of the term to mean specifically the image of the build environment.

I would advise checking prior instances of "build image" and disambiguate them with "build environment image" and "tenant build image". A build platform will attest to itself, but it may also mount a container including a tenant's build toolchain for executing a build request, so that's an important distinction to make.

Clarify that the build executor must be a measured component of the build environment image.

I always think of requests as messages. Perhaps,

"A user-provided message to the build platform that is used to assign a build to a pre-provisioned build environment on a hosted build process."

But this could be splitting hairs.

Fair point. This isn't really about the exchanged messages, but about the action of assigning and dispatching a tenant's build process to a pre-deployed build environment. More recently, I've been using the term "build environment dispatch" for this step in the build environment's lifecycle, which is hopefully a little clearer.

That is, generating an in-toto attestation about the entire initial state of the build environment?

We may run into confusion here between attestation and attestation:

The process of vouching for the accuracy of information.

from TCG Glossary, and

An authenticated statement (metadata) about a software artifact or collection of software artifacts.

from SLSA Terminology

It might be worth adding a note to clarify to readers who have familiarity with both terms.

"an the build."... executor? agent?

How about:

and then list some of the requirements?

I'm worried that this definition precludes any sort of distributed build from ever meeting SLSA L4 - it seems to assume that a build is always hermetic within a single build environment, and so easily described as host + VM + filesystem + command -> output. Almost all of the high-trust builds produced by Google, for example, are produced via distributed systems across multiple hosts, where the network, virtual filesystems, etc are inextricably linked to the process. Many could not be produced on any single machine in any reasonable amount of time, if at all. (Needing many TiBs of scratch space in total, many core-days of work, etc.)

I'd have no objection to defining a SLSA framework for hermetic single-host builds, if that is independently useful, but for "L4" where the implicit assumption is that all high-trust builders should aim to achieve it, I'm not yet convinced that this is the correct successor to L3. Though even here, "trust of software" seems still necessary, in that I don't know how to go from a description of a build to a fully realized set of input files without already having to have trusted that some build platform software has interpreted it correctly.

Perhaps the right target is a broadened version of the same: a chain of hardware-rooted build attestations to what software was running on each node leveraged in the build process, with that software in turn attesting what environment it set up locally, etc? This would make it easier to be "tamper evident" for hardware attacks, though still require trusting that the build platform software is sufficiently bug- and backdoor-free.

Failing that, @TomHennen 's comment elsewhere about "independently reproducible" might be a better choice for L4. Though that may also fail on practicality grounds: I'm not sure of many systems that have ever achieved multi-party bitwise reproducibility (I don't think Debian is there yet?), and I don't know what that would look like for closed-source systems that only execute on one build platform in practice.

Perhaps the right target is a broadened version of the same: a chain of hardware-rooted build attestations to what software was running on each node leveraged in the build process, with that software in turn attesting what environment it set up locally, etc?

@EricBurnett I agree with this target (and I think it's consistent with the spirit - the build environment is potentially distributed). It would be a small change in the next line to make it more explicit -

- (i.e., VM/container image, boot process and filesystem)
+ (i.e., VM/container image, boot process, and filesystem, for each host in the build environment)

There are reasons for the disk image to not be entirely measured, so this seems like it could be too coarse of a requirement. There are ways security-critical components of user space are measured. They go past the PCRs 0-7 in the TCG-compliant measured boot link.

This whole disk integrity would disallow content-addressed build caches that already have SLSA attestations, such as what Bazel.build uses for performance.

The fact of the matter is that we have bespoke ways of evaluating attestation evidence and specifying policy for their acceptance. There is no standard since OSes consider different things to be security-critical.

Perhaps, "every file read from disk must be integrity-protected by some means traceable to the build environment identity or build request"

I'll be closing this PR soon. Let's move this discussion to #1107 !